Материалы курса «Подготовка к Аттестации по Платформе 8.2» – Раздел 3, задача 3.06 «Командировки»
Это еще одна задача раздела “Расчетные задачи” – задача 3.06 “Командировки”
Комментарий Павла
Для начала я выбрал не самую сложную задачу, однако в ней необходимо предусмотреть сторнирование записей и реализовать возможность ввода записей с “перетекающим” периодом действия записи, нарисовать диаграмму Ганта.
- Изучите материалы задачи.
- Вопросы, возникшие в ходе изучения этих материалов, задавайте в комментариях на текущей странице. Ответы преподавателя и комментарии других участников будут Вам доступны, только если Вы залогинены и у Вас есть доступ в Мастер-группу.
- Общие вопросы по курсу (в т.ч. организационные) задавайте на стартовой странице.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (83):
Комментарии закрыты
Добрый день, Павел!
Решая эту задачу остановился на этапе расчета суммы для доп. начислений с видом Премия. Уперся в проблему – не получается запросом получить базу для Премии. Процедура почти такая же как и у вас. Первый запрос в пакете для оклада сделал выборку нормально. А вот второй запрос для премии всё время пустой, хотя предварительные движения документ НачислениеЗарплаты делает правильно. Пробовал много вариантов, но причину не нашёл. Посмотрите процедуру, может вы увидите где я ошибся или знаете причины в другом?
Процедура Расчет(Регистратор) Экспорт
НаборЗаписей = РегистрыРасчета.ОсновныеНачисления.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Значение = Регистратор;
НаборЗаписей.Прочитать();
Доп_НаборЗаписей = РегистрыРасчета.ДополнительныеНачисления.СоздатьНаборЗаписей();
Доп_НаборЗаписей.Отбор.Регистратор.Значение = Регистратор;
Доп_НаборЗаписей.Прочитать();
// Основные начисления
Запрос = Новый Запрос;
Запрос.Текст =
“ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия КАК ПлановыйПериодДействия,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия КАК ФактическийПериодДействия,
| ОсновныеНачисленияДанныеГрафика.ВидРасчета,
| ОсновныеНачисленияДанныеГрафика.Подразделение
|ПОМЕСТИТЬ ДанныеГрафика
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(Регистратор = &Регистратор) КАК ОсновныеНачисленияДанныеГрафика
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДанныеГрафика.НомерСтроки,
| ДанныеГрафика.ПлановыйПериодДействия,
| ДанныеГрафика.ФактическийПериодДействия,
| ДанныеГрафика.ВидРасчета,
| ДанныеГрафика.Подразделение,
| СтавкиОкладов.Ставка
|ИЗ
| ДанныеГрафика КАК ДанныеГрафика
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтавкиОкладов КАК СтавкиОкладов
| ПО ДанныеГрафика.Подразделение = СтавкиОкладов.Подразделение
|ГДЕ
| СтавкиОкладов.ОтработанныеЧасыМин = ДанныеГрафика.ФактическийПериодДействия
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДополнительныеНачисленияБазаОсновныеНачисления.НомерСтроки,
| ДополнительныеНачисленияБазаОсновныеНачисления.Параметр,
| ДополнительныеНачисленияБазаОсновныеНачисления.СуммаБаза,
| ДополнительныеНачисленияБазаОсновныеНачисления.ВидРасчета
|ИЗ
| РегистрРасчета.ДополнительныеНачисления.БазаОсновныеНачисления(&Измерения, &Измерения, , Регистратор = &Регистратор) КАК ДополнительныеНачисленияБазаОсновныеНачисления”;
Измерения = Новый Массив(1);
Измерения[0] = “Сотрудник”;
Запрос.УстановитьПараметр(“Измерения”, Измерения);
Запрос.УстановитьПараметр(“Регистратор”, Регистратор);
МассивЗапросов = Запрос.ВыполнитьПакет();
Выборка = МассивЗапросов[1].Выбрать();
Отбор = Новый Структура(“НомерСтроки”, 0) ;
Для каждого Запись Из НаборЗаписей Цикл
Отбор.НомерСтроки = Запись.НомерСтроки;
Если Выборка.НайтиСледующий(Отбор) Тогда
Если Выборка.ВидРасчета = ПланыВидовРасчета.ОсновныеНачисления.Оклад Тогда
Запись.Сумма = Выборка.Ставка / Выборка.ПлановыйПериодДействия * Выборка.ФактическийПериодДействия;
ИначеЕсли Выборка.ВидРасчета = ПланыВидовРасчета.ОсновныеНачисления.Командировка Тогда
КонецЕсли;
КонецЕсли;
Выборка.Сбросить();
КонецЦикла;
НаборЗаписей.Записать(,,Ложь);
// Доп начисления
Выборка = МассивЗапросов[2].Выбрать();
Для каждого Запись Из Доп_НаборЗаписей Цикл
Отбор.НомерСтроки = Запись.НомерСтроки;
Запись.Сумма = 0;
Если Выборка.НайтиСледующий(Отбор) Тогда
Если Выборка.ВидРасчета = ПланыВидовРасчета.ДополнительныеНачисления.Премия Тогда
Запись.Сумма = Выборка.СуммаБаза * Выборка.Параметр / 100;
КонецЕсли;
КонецЕсли;
Выборка.Сбросить();
КонецЦикла;
Доп_НаборЗаписей.Записать();
КонецПроцедуры
Нашел, причину! Отмените комментарий
Здравствуйте!
Вопросы по задаче 3.06 командировки:
1) Все же как сторно влияет на Перерасчеты. Допустим в январе начислили Оклад за полный месяц, в феврале Командировка сторнирует часть январского Оклада. Если бы у нас начислялась например Премия в феврале по Базе за январский Оклад, то система бы брала нетронутый январский Оклад, а нам же нужно взять Базу уже с учетом Сторно. Как это сделать?
2) “GROOVY 07.11.2014 …. В регистре сведений можно создать 2 ресурса: кол часов по пятидневке и кол часов по шестидневке и брать любой из них в качестве данных графика.” Может, я чего-то не понимаю, но выходит вы предлагаете создать 2 ресурса в РС и его запись получается будет иметь вид: Дата – 01.01, График – Пятидневка, КолЧасовПоПятидневке – 8, КолЧасовПоШестидневке – 8.
3) И последнее. Можно ли выбрать ВСЮ информацию например из РР ДопНачисления с левым соединением с Базовыми таблицами ОсновноеНачисление и ДопНачисление (естественно с фильтром по Регистратору) положить все это во Врем. табл. и дальше запрос-пакетами к ней устанавливать доп фильтры например по ВР. Это позволит не создавать 1 мега-запрос, к которому мы будет клеить дополнительную информацию из РС или использовать Разрез для одной из Баз – это может быть не устойчиво. А так мы из основной Врем. табл. берем нужные данные с нужными фильтрами и спокойно обрабатываем отдельно.
1. База будет взята в соответствии с настройкой “Зависимость по базе” либо по периоду действия, либо по периоду регистрации. Период регистрации сторно будет февральский, а действия – январь.
2. Да.
3. Это не оптимально, но можно.
Добрый день.
Вопрос. В данной и похожих задачах есть РС, где указываем шкалу зависимости оклада (или еще чего) от отработанного времени. При расчетах ЗП соединяем таблицы с данным РС. Данный регистр сведений обычно не подчинен регистратору. Надо ли добиваться как в задачах с валютой, чтобы данные из этого регистра отразились в документе начисления оклада или это будет излишним? Или делать документ для заполнения данного регистра?
На мой взгляд это будет излишним.
Павел, добрый день!
Где все таки посмотреть пример построения диаграммы Ганта? По указанной вами ссылке /2012/06/12/dev-att-15-vacations/ пишет, что у меня нет доступа к данному разделу.
http://курсы-по-1с.рф/dev-attestation/startpage/task-3_21-vacations/
Добрый день,
Вы обещали ссылку на видео с диаграммой Ганта.
http://курсы-по-1с.рф/dev-attestation/startpage/task-3_21-vacations/
Здравствуйте!
Есть небольшая неточность (возможно не существенная) в решении этой задачи. Мы всегда определяем ставку для оклада исходя из фактически отработанного времени, в том числе и для сторно записей. Сторнировать все-таки нужно столько же, сколько было начислено за сторнируемый период.
Самое простое (по-моему) сохранять ставку при расчете оклада в реквизите записи регистра расчета. И при сторнировании использовать ставку из реквизита записи, а не из выборки.
С уважением,
Антон
Здравствуйте Павел!
В условии задачи сказано “Часовая ставка для расчета командировки определяется как
сумма всех начислений за предыдущий месяц, деленная на количество рабочих часов в
предыдущем месяце”, т.е. СуммаБаза/ФактЧасовБаза. Правильно ли использовать в качестве ФактЧасовБаза поле из таблицы данных графика КолЧасовБазовыйПериод, в нем же сидит норма за базовый период? Или надо добавить в РР ресурс с суммой часов и брать его из таблицы базовых данных?
Рабочих = можно брать дни/часы базы
Отработанных = нужно ресурс создавать
Ну почти так.
Здравствуйте!
Тут реально есть проблема. В условии сказано: “Все работники работают по пятидневному графику…”. Т.е. командировка – это “отклонение” от графика сотрудника, и норму нужно определять по пятидневке. Т.о. (по-моему) все указывает на то, что в этой задаче нужно норму часов сохранять в ресурсе записи регистра при расчете оклада (что бы потом получить её как базу) . Или в запросе брать сумму часов за базовый период прямо из регистра сведений (но это не приветствуется).
С уважением,
Антон
Никакой проблемы.
Берем сумму всех начислений и делим на количество рабочих часов. Где хранить раб часы – решать Вам. Я бы хранил в регистре сведений.
Самое простое решение – это конечно взять норму часов из графика (в реале я бы так и сделал). Но в требованиях к экзамену сказано, что за это снижают бал. Нужно все расчетными механизмами делать.
Мне кажется мы не понимаем друг друга :)
В регистре сведений можно создать 2 ресурса: кол часов по пятидневке и кол часов по шестидневке и брать любой из них в качестве данных графика.
Добрый день, Павел!
Подскажите, пожалуйста: в каком РС нужно создать 2 ресурса? В ПроизводственныйКалендарь (и как тогда эти ресурсы должны заполняться) или создать отдельный РС с измерением Период и двумя выше указанными ресурсами?
Приветствую.
Плановые часы храним а РС, в производственном календаре, отработанные в регистре расчета.
Павел, не совсем понятен механизм с 2-мя ресурсами. Правильно я понял, что в производственном календаре нужно создать два ресурса – ЧасыДляПятидневки и ЧасыДляШестидневки. И когда измерение График = “пятидневка”, то заполняется ресурс ЧасыДляПятидневки (он же указывается в РР на закладке “Основные” как Значение графика)? А когда измерение График = “шестидневка”, то заполняется ресурс ЧасыДляШестидневки?
Если я не правильно понял вас, могли бы написать ту структуру РС, о которой вы говорите?
И как тогда сделать правильный расчет командирвки, если в РР на закладке “Основные” как Значение графика будет указан ресурс ЧасыДляПятидневки, ведь для графика Шестидневка он будет пустой? Создавать новый РР для шестидневки?
Почти. Часы в РР я бы заполнял всегда, так удобнее брать базу.
В РР ресурсы “Отработано по 5” и “Отработано по 6”.
В РС – “График” и “Кол часов”
В РР значение графика нужно указать “Кол часов”. Не понял почему для шестидневки оно будет пустым?
Если так, как я дума (ресурсы ЧасыДляШестидневки и ЧасыДляПятидневки не в РР, а в РС), то для каждого графика (пятидневки и шестидневки) заполняются соответсвующие ресурсы, иначе нет смысла делать 2 ресурса в РС. А судя из вашего последнего ответа так оно и есть. Благодарю за ответ.
1. Но в условии задачи сказано «Часовая ставка для расчета командировки определяется как сумма всех начислений за предыдущий месяц, деленная на количество рабочих часов в предыдущем месяце”. Значит нам нужно брать не фактические часы, а плановые часы по графику пятидневка. Я правильно понял условие задачи?
2. И если я правильно понял условия расчета командировки, то тогда как правильно взять плановые часы базового периода по пятидневки для расчета командировки?, если слушатель курса kan200823 (см. выше) утверждает, что: “Самое простое решение — это конечно взять норму часов из графика (в реале я бы так и сделал). Но в требованиях к экзамену сказано, что за это снижают бал. Нужно все расчетными механизмами делать.”
Вы же в ответ написали: “…В регистре сведений можно создать 2 ресурса: кол часов по пятидневке и кол часов по шестидневке и брать любой из них в качестве данных графика.”
Может в РР в реквизитах хранить плановые часы периода?
1. Правильно.
2. Брать часы по базе надо, запросом к таблице ДанныеГрафика. В РР плановые часы хранить нельзя, так как база по часам будет множиться при вытеснении и сторно.
Если брать часы по базе запросом к таблице ДанныеГрафика, то запрос к этой таблице в значения ОсновныеНачисленияДанныеГрафика.КолЧасовПериодДействия и ОсновныеНачисленияДанныеГрафика.КолЧасовБазовыйПериод почему то берет данные по графику шестидневки, а у нас в базовом периоде сотрудник работал по пятидневному графику. Т. е. база будет рассчитана не по условию задачи. Почему и возник вопрос: откуда взять число плановых часов за базовый период по пятидневке при расчете командировки?
Либо брать по шестидневке, либо думать по какому графику брать план, так как в условии сказано, что работать могут по любым графикам. Кроме того есть начисления независящие от отработанного времени.
Премия не сторнируется вместе с окладом. Вы говорите, что она попадет в перерасчеты. Но получается что она перерасчитается прошлым периодом, когда все налоги уже уплачены? Как это изменить?
В задаче нет налогов. А если бы были, то хранились в плане видов расчета который зависит от базы по периоду регистрации.
Конкретно по налогам понятно, спасибо :) . Интересует более общий вопрос.
Для чего вообще нужно дополнение – чтобы в текущем периоде зафиксировать корректировку прошлого периода, не “ломая” сам прошлый период (иначе можно просто зайти в старый документ да и поправить что нужно).
Но если мы сказали “а” то надо бы и “б” – то есть откорректировали оклад в текущем периоде, нужно и все зависимые от него суммы (премия) откорректировать также в ТЕКУЩЕМ периоде.
Это как-то можно реализовать (в частности в прикладных решениях может знаете как реализовано)?
Дополнения позволяют формировать записи-сторно, без них нельзя “вытеснить” задним числом запись.
Вопрос Вы не прочитали мой. Еще раз:
Если мы с помощью дополнения корректируем в текущем периоде оклад прошлого периода, то как В ТЕКУЩЕМ же периоде откорректировать и все зависимые от оклада ПРОШЛЫЕ начисления?
Ну так у зависимых же поменяется БАЗА. Если зависимость по периоду регистрации выставлена. Прошлые мы трогать не будем, введем новые которые получат измененную базу.
ЗЫ: На этом курсе мы полагаем, что вы обладаете навыками проектирования РР в рамках продвинутого курса
Задача действительно интересна. Ведь при сторнировании оклада сумма сторно скорее всего получится неверно расчитана. Предположим прошлый месяц сотрудник отработал полностью – 160 часов. В этом месяце мы вводим командировку за прошлый месяц на 30 часов. И ставка для расчета сторно по окладу у нас берется совершенно другая. Я прекрасно понимаю что такова постановка задачи, но …
Будет ли это считаться ошибкой на сертификации? Или на такое закроют глаза?
Не могу ответить. Это вопрос к экзаменаторам.
При сторнировании оклада сумма сторно получится неверно расчитана. Предположим прошлый месяц сотрудник отработал полностью – 160 часов. В этом месяце мы вводим командировку за прошлый месяц на 30 часов. И ставка для расчета сторно по окладу у нас берется совершенно другая. То есть оклад отсторнируется НЕВЕРНО. На этот НЕДОЧЕТ мы умышленно идем, чтобы упростить задачу? Или это нужно как то переделать?
Ставку следует хранить в реквизите записи оклада и брать от туда. Тогда все будет считаться корректно.
Согласен наполовину. Но если идти дальше – у нас и сама ставка плавающая, то есть она сама зависит от количества часов. Т.е. в нашем случае, при сторнировании может уменьшиться и ставка – вот как ее пересчитать?..
Не думаю, что в рамках сертификационных задач ее нужно пересчитывать. А так, задача интересная. Получается нужно фиксировать сначала время (и его вытеснять), а уже потом брать время как базу и пересчитывать результат.
Здравствуйте.
В условиях задачи сказано:
“Сотрудники предприятия получают оплату по окладу пропорционально отработанному времени в
часах. Сумма начисления по окладу определяется как начальное значение оклада, деленное на
количество отработанных часов в том же периоде, что и фактически отработанные часы.”
В решении этой задачи у Вас написано:
Если Запись.ВидРасчета = ПланыВидовРасчета.ОсновныеНачисления.Оклад
Тогда
Запись.Сумма = Выборка.ФактЧасов * Выборка.Ставка;
Мне кажется тут ошибка. Ведь нет НормаЧасов. А расчет должен быть такой:
Запись.Сумма = Выборка.ФактЧасов / Выборка.НормаЧасов * Выборка.Ставка
Павел, скажите, правильно я понимаю?
Да, я видимо ошибся. Спасибо.
Добрый день.
Не вполне ясно, кто все-таки ошибся.
По версии из видеоурока:
Сумма = ФактЧасов * Ставка, что отражает условие задачи и согласуется со здравым смыслом.
Поясните, пожалуйста, при чем тут НормаЧасов?
Ошибка в тексте задачи. Если сказано “Пропорционально”, то нужна норма и факт часов. А в тексте “Сумма начисления по окладу определяется как начальное значение оклада, деленное на количество отработанных часов в том же периоде, что и фактически отработанные часы” – полный бред.
Павел, что означает фразы в задачах:
1)Каждый сотрудник может одновременно работать в нескольких подразделениях компании, т.е совместительство допускается
Каждый сотрудник компании работает по своему собственному графику.При одновременной работе в разных подразделениях у каждого сотрудника в конкретном подразделении может быть свой собственный график.
Такая ли будет структура:РС(Регистр Сведений Графики) РР(Регистр расчета Основные начисления)
1)РС: Измерения: Дата,Сотрудник,Подразделение
Ресурс:Значение
2)РР: Измерения:Сотрудник(связь с графиком по “Сотрудник”)
Реквизит:
Подразделение(так как совместительство допускается)-связь с РС по измерению “Подразделение”.
1) Да допускается работа в разных подразделениях. Если есть условия по работе со штатным расписанием, то в регистре сведений сотрудник будет измерением.
1) Дата там зачем?
2) ????
Что за штатное расписание?
Дата потому что РС графики)
Павел еще смутило, что в реальной задаче ставки указываются в разрезе подразделений. Начисления также все делал в разрезе подразделений.
Не могли бы вы подсказать, как вывести диаграмму ганта с подчинением точек:
сотрудник – подразделение.
У точки есть свойство “Родитель”… Дальше я думаю понятно.
Павел, добрый день.
А саму зависимость оклада от отработанного времени можно ли реализовать так:
Начальное значение часов – Конечное значение часов – Оклад, чтобы не заморачиваться со вложенными запросами – т.е. оклад при соединении определиться попаданием факта часов в период ? Не будет ли это считаться ошибкой или упрощением ?
Не понял. Поясните подробнее.
Создать РС с измерениями Начальное значение часов, Конечное значение часов, Оклад.
Т.е для условия:
Отдел внедрения до 60 2000
Отдел внедрения от 60 до 130 2500
Отдел внедрения от 130 3500
запись будет выглядеть:
Отдел внедрения 0 60 2000
Отдел внедрения 61 130 2500
Отдел внедрения 131 10000 3500
Так это, вроде, правильно.
В какой задаче рисовали диаграмму Ганта? Не в расчетной? Можно номер? (а то я часть задач пропустил иду по расчетным.)
/2012/06/12/dev-att-15-vacations/
Как сторнировать премию, если командировка вытесняет оклад задним числом?
Премия попадет в таблицу перерасчетов.
3. Как-то в одном из уроков Вы сказали, что требуется реализовывать алгоритмы не привязанные к предопределенным видам начислений. И реализовывали через Перечисление. Это обязательное требование для всех задач? Или такое требование может присутствовать в тексте задачи?
Требование в тексте задачи “Требуется дать возможность пользователю самостоятельно создавать виды расчета и привязывать их к стандартным алгоритмам”.
2. Для расчета даты использовал такой цикл в обработке проведения:
.
Для каждого Стр Из ОсновныеНачисления Цикл
Движение = Движения.ОсновныеНачисления.Добавить();
ЗаполнитьЗначенияСвойств(Движение, Стр);
Движение.ПериодРегистрации = Дата;
Если Движение.ВидРасчета.ВидРасчета = ПредопределенноеЗначение(“Перечисление.ВидыРасчета.Командировка”) Тогда
Пока НачалоМесяца(Движение.ПериодДействияНачало)<>НачалоМесяца(Движение.ПериодДействияКонец) Цикл
ДубльДвижение = Движения.ОсновныеНачисления.Добавить();
ЗаполнитьЗначенияСвойств(ДубльДвижение, Движение);
ДубльДвижение.ПериодДействияКонец = КонецМесяца(Движение.ПериодДействияНачало);
Движение.ПериодДействияНачало = КонецМесяца(Движение.ПериодДействияНачало)+24*60*60;
КонецЦикла;
КонецЕсли;
КонецЦикла;
.
.
Чем это грозит? Допустима ли такая реализация? (можно поправить на КонецДня, принципиально алгоритм не изменится)
На что тут надо обратить внимание? Куда хотите писать “КонецДня”?
У Вас реализация через запрос.
У меня реализация через сравнение один месяц или два разных и последующее последовательное смещение даты начала.
Прошу Вас оценить рационален / нет мой вариант решения.
(на”КоенцДня” можно не обращать внимание. я как раз и написал, что на него не следует обращать внимание.)
Извините, но я правда не понимаю в чем рационализаторство… Можно задачу решить просто перебирая дни, часы, секунды… Разность в месяцах быстрее и удобнее рассчитать в запросе.
На мой взгляд мой вариант ни более и не менее рационален чем Ваш.
В Вашем варианте запрос, и дополнительные вычисления для начала и конца месяца, в которых нет “разделения” на строчки.
В моем варианте цикл будет попадать в тело цикла реже, т.к. только пир выполнении условия требуется заменять дату.
Количество итераци при проходе по “разделяющимся” строчкам одинаково.
.
Думаю разницу в производительности можно будет отследить на документах с количеством строк превышающих тысячи, может сотни тысяч строк – не ранее. (хотя я конечно не тестировал производительность).
.
Вопрос:
1) присутствуют ли в моем решении очевидные недостатки, которых я не заметил?
2) Чем “быстрее и удобнее рассчитать в запросе”?
У нас курс “подготовка к аттестации”, а не “красота кода и производительность”.
Запрос исполняется средствами SQL сервера, код – средствами сервера приложений. Что быстрее – проверьте сами, введите тестовый пример на нормальном тест-стенде, проведите нагрузочное тестирование, поделитесь результатами. У меня тест-стенда под рукой нет. Красота кода и удобство – дело субъективное.
Про скорость: у Вас бОльшее количество операторов используется: приведение дат к началу/концу месяца, проверка равенства дат, непонятно зачем использована функция ПредопределенноеЗначение. Думаю, что Ваш код будет существенно уступать в производительности моему.
Понял. Благодарю за ответ.
1. Добавил Ресурс ОтработаноЧасов в ОсновныеНачисления, в результате считаю базу по часам “пятидневки” для командировки в шестидневке без всякого разделения на Пяти-шести-дневные ресурсы РС РабочийКалендарь. Это правомочно?
Пожалуйста приводите контекст вопроса, мне довольно сложно переключаться между почти 40 разобранными задачами.
Добавление ресурса в РР даст возможность получать фактически отработанные часы в базовом периоде.
Четырнадцатая задача. Вы говорите, что-то вроде “что бы делить начисления прошлого периода на “пятидневные” часы прошлого периода и умножать на “шестидневные” часы текущего периода для начисления командировки – необходимо вводить два ресурса в регистре сведений”.
Я же решаю ту же задачу через добаление ресурса в РР. Чем это черевато?
И как Вы получаете “количество рабочих часов в предыдущем месяце” не “отработанных“, а рабочих? Если сотрудник вообще не работал в прошлом месяце?
Какой-то странный глюк форума. Не могу отправить ответ
“Понял. Благодарю.”
выдает абракадабру в какой-то неверной кодировке.
Или это защита от коротких ответов так настроена?
Насколько понимаю, при расчете оклада в видеоматериалах допущена неточность, поэтому сумма начислений по 60000 руб (ставка умноженная на кол часов). По условию сумма начисления определяется как оклад, деленных на количество часов в периоде* Факт часы
Павел, и все-таки вопрос у меня по настройке ведущих начислений.
Как я понимаю, лишние галки в этих настройках тоже не особо приветствуются на экзамене.
Итак.
В данной задаче для Оклада ведущим будет Командировка, т.к. она вытесняет Оклад.
Для Командировки ведущими будут и Оклад и Премя, т.к. они базовые.
Для Премии ведущим будет Оклад, т.к. он базовый и Командировка, т.к. она вытесняет Оклад.
При попытке сохранения конфигурации Платформа просит в Ведущие для Оклада добавить Оклад или удалить Командировку, а для Командировки: добавить Командировку или удалить Оклад.
Т.е. в итоге в ведущих у Оклада будет: Оклад, Командировка, Премия.
У Командировки: Оклад, Командировка.
У Премии: Оклад, Командировка.
Каким будет Ваш вариант?
Командировка не будет ведущей для оклада! … эээммм….
Ведущие – это виды расчета которые образуют базу для расчета текущего вида или влияют на базу косвенно. Ведущие настраиваются по следующим правилам: Вытесняющие виды расчета не попадают в “Ведущие”, так как регистрация перерасчетов при вытестении производится платформой самостоятельно. Так называемые “Перерасчеты по вытеснению”. А вот Базовые как правило полностью входят в ведущие (и базовые базовых).
благодарю за ответ.
просто я пробовал сделать перерасчет командировки в отдельном документе так, чтобы это повлияло на оклад… и в результате в таблице Перерасчета не увидел регистрации необходимости перерасчета Оклада…
Видимо что-то не так сделал. Попробую еще разок.
Добрый день.
Хорошее решение.
Есть вопросы.
1. Примера с Диаграммой Ганта я не видел ни в 5 ни в 6 задаче ни в этй, хотя в данном решении вы говорите, что уже делали эту диаграмму и не хотите повторяться.
2. Можно ли увидеть пример блокировки на регистрах расчета?
3. Каким образом сторнировать премию от сторнируемого оклада? Например, задним числом ввели командировку, она отсторнировала оклад, а от этого оклада была расчитана премия. Как с ней быть?
4. Оклад у вас считается не верно. Его еще нужно поделить на количество рабочих дней в периоде действия.
5. В 6-ом задании у вас есть недочет. При осуществлении перерасчета те виды расчета, которые НЕ нужно перерасчитывать, сбрасываются в ноль.
Не совсем по данной задаче:
6. Как в данном задании было бы верным Настроить ведущие виды расчета, если потребовались бы Перерасчеты?
7. В методе “Записать” набора записей РегистраРасчета есть параметр “ЗаписьПерерасчетов”. Есть ли необходимость выставлять его в Истина при перерасчете?
8. При перерасчете, после выполнения Записи набора РегистраРасчета происходит регистрация перерасчетов также и по тем видам расчета, по которым не производился в данный момент перерасчет. Не обращать на это внимания?
Видео с диаграммой Ганта выложу в течении пары дней. Сорри, вроде должна была быть в одной из первых задач.
Блокировка накладывается элементарно используя свойство набора записей “БлокироватьДляИзменения”.
Премия “сторнируется” при перерасчете. Перерасчеты реализовывать не требовалось.
Перерасчеты следует настраивать по базе. то есть если вид расчета использует чью либо базу или зависит неявно по базе то эти виды расчета должны быть указаны в качестве ведущих.
ЗаписьПерерасчетов нужно устанавливать ИСТИНА в том случае если нужно проанализировать и зарегистрировать необходимость перерасчета. По умолчанию параметр и так устанавливается в ИСТИНА.
Механизм перерасчетов анализирует весь набор записей нет возможности произвести регистрацию только необходимых видов расчета. Ну исключая вообще ручную регистрацию.
“Блокировка накладывается элементарно используя свойство набора записей «БлокироватьДляИзменения».” Разве РР можно блокировать?
Блокировать можно любую таблицу. От констант до бизнес-процессов.
Тогда при решении расчетной задачи будет ли ошибкой отсутствие блокировки для РР?
В августе 2016 года на сертификации за это балы не снижали.
Простите, никак не могу понять фразу:
” Сумма начисления по окладу определяется как начальное значение оклада, деленное на количество отработанных часов в том же периоде, что и фактически отработанные часы.”
Как все-таки оклад считается?
почитал оригинал, стало яснее.. прошу прощения.
Добрый день.
Предлагаю задачу 3.31
Тарифную шкалу реализовал в виде регистра сведений. Надо ли все параметры шкалы (отработано часов, ставка) заносить в регистр расчетов (для восстановления используемой шкалы) или достаточно ограничиться значением ставки?
На сертификации это не должно повлечь изменение оценки. В реальности я рекомендую все данные для расчета хранить в регистре расчета.